4G下要等2.4秒的首图，压完之后只剩0.4秒

这份操作说明适用的场景很具体：手机上打开页面，首屏那张大图迟迟不出来，白框先撑着，两秒多之后图才刷下来。下面的工序按顺序做，不要跳步，尤其不要先去调压缩质量——顺序错了，后面几步的数字全是白算的。

动手前要备齐的五样东西

第一样是合格的源图。原图短边至少要达到最终展示宽度的两倍，三倍更稳妥；如果手上只有从聊天软件里导出来的图，短边往往已经被压到 1080 甚至 720，再怎么处理也只是在压缩痕迹上叠压缩痕迹，这种图直接退回去重新要。第二样是一份图片资产清单，把页面上的图分成四类分别统计张数和体积：首屏主图、列表缩略图、详情页内文图、图标与装饰件。多数网页制作项目做完这一步就会发现，拖慢首屏的其实只有三到五张图，其余几十张都在折叠线以下。

第三样是转码工具，命令行用 sharp 或 cwebp、avifenc，不想装环境就用浏览器里的 Squoosh，单张手工调参很直观。第四样是真机两台：一台三年前的安卓千元机，一台任意 iPhone，模拟器测不出解码耗时的差别。第五样是确认服务端或 CDN 支不支持按请求头返回不同格式，这一条直接决定第三步能不能落地，问运维要一句准话，不要自己猜。

第一步：量出真实展示宽度，别照着设计稿的尺寸出图

打开 Chrome 开发者工具，切到 390 宽度的手机视图，用元素选择器逐个点图片，读出它的 CSS 展示宽度。一个典型结果是：首屏主图 390，两列列表的缩略图 172，作者头像 40，底部合作方标识 88。然后乘以设备像素比。这里有个常见误区是照着 DPR 3 全乘三倍，实际上超过两倍之后肉眼分辨率提升非常有限，而体积要涨一倍多，取 2 倍、最多 2.5 倍就够。于是需要准备的实际像素宽度落在：主图 780，缩略图 344 到 430，头像 80，标识 176。

校验方法：在开发者工具的元素面板上把鼠标悬停到图片节点，会同时显示渲染尺寸和固有尺寸。固有尺寸除以渲染尺寸，比值大于 2.5 说明这张图切大了，纯属浪费流量；比值小于 1 说明被拉伸了，图会发虚。把每张图的这个比值抄在清单上，全部落进 1.5 到 2.5 之间才算过关。

第二步：尺寸定四档，不要一个宽度出一张

四档定成 640、828、1080、1440。这四个数不是随手取的：640 对应老旧小屏和二列缩略图，828 覆盖主流 390 到 414 逻辑宽度的两倍档，1080 给 DPR 3 的机型，1440 兼顾平板竖屏和折叠屏展开态。相邻档位宽度差三成左右，是体积收益和缓存条目数之间比较划算的一个折中。见过有团队按 320 起步每隔 160 出一档，一共十一档，构建时间从 40 秒涨到 4 分钟，实际命中的仍然是那三四档。

校验方法：把同一张源图的四档产物按字节列出来，相邻两档的体积差应当落在 35% 到 60% 之间。如果相邻两档只差不到 20%，说明档位排得太密，删掉中间一档；如果某两档之间差了三倍以上，中间需要补一档，否则窄屏机型会被迫下载大一档的图。这份档位表定下来之后可以固化到构建配置里，后续网页制作改版时直接复用，不必每次重新推导。

第三步：一张源图出三种格式，排好回退链

顺序是 AVIF、WebP、JPEG。拿一张 1.8MB、3000 像素宽的活动主图做基准，切到 828 宽之后：JPEG 质量 78 大约 280KB，WebP 质量 75 大约 210 到 260KB，AVIF 质量 50 大约 130 到 170KB。用 picture 元素包裹，里面按 avif、webp 的顺序放两个 source，最后留一个 img 标签指向 JPEG 兜底，浏览器会取第一个它认识的。透明图和纯色扁平插画走另一条线，AVIF 之后回退到 PNG 而不是 JPEG，否则透明区域会变成黑块。这一段是整套网页制作流程里收益最大的一步，单靠换格式通常就能把首屏图片总量砍掉四到五成。

校验方法：在网络面板打开类型列，逐个确认首屏图片返回的确实是 avif 或 webp，而不是 jpeg；同时点开响应头看 content-type 与文件后缀是否一致。然后拿备好的两台真机各开一次页面，安卓机应当拿到 AVIF，老版本 Safari 应当自动落到 WebP 或 JPEG，图正常显示才算回退链通了。

第四步：压缩参数只需盯住三个开关

第一个开关是质量值。JPEG 用 mozjpeg 编码器，质量给 72 到 78；WebP 给 70 到 78；AVIF 给 45 到 55，AVIF 的数值体系和前两者不同，给到 75 就已经过剩了。第二个开关是色度二次采样。人像、风景、产品实拍用 4:2:0 没问题，能再省一到两成；但图上如果压着细笔画的红色文字、品牌标识或者截图界面，必须改成 4:4:4，否则彩色边缘会糊成一片。第三个开关是元数据，相机拍的原图里带着缩略图、拍摄参数、色彩配置，一张图能占 20 到 60KB，转码时统一剥掉，只保留 sRGB 的色彩描述。

校验方法分两道。一道是体积红线：首屏单张不超过 150KB，首屏图片合计不超过 400KB，正文内单张不超过 100KB，图标不超过 8KB。另一道是肉眼验收：把成品放大到 200%，重点看三处——天空和背景渐变有没有出现一圈圈色带，深色区域有没有块状噪点，图上的小字边缘有没有彩色毛边。任何一处出问题，把质量值往上加 5 再压一次，而不是直接退回原图。

第五步：srcset 和 sizes 必须成对写

在 img 标签的 srcset 属性里按 640w、828w、1080w、1440w 依次列出四档地址，同时在 sizes 属性里描述这张图在不同视口下占多宽。首屏通栏图写成 100vw；两列列表的缩略图写成 50vw；带最大宽度限制的内文图写成条件式，比如视口不小于 768 时占 704 像素，否则占 100vw。只写 srcset 不写 sizes 是很常见的疏漏，此时浏览器一律按 100vw 估算，两列布局里每张缩略图都会取大一档，白白多下四成流量，而页面看上去完全正常，不做校验根本发现不了。

校验方法：在控制台里取出图片节点的 currentSrc 属性，它返回浏览器最终选中的那个地址。分别在 390 和 768 两种宽度下刷新页面各读一次，390 下缩略图应当取 640w 档，主图取 828w 档；768 下主图应当升到 1080w 或 1440w。取错档说明 sizes 描述与实际布局对不上，回去改 sizes，不要去动 srcset。

第六步：排加载优先级，首屏抢跑其余排队

首屏那张最大的图不要挂懒加载，反而要给它加高优先级标记，必要时在页面头部再加一条预加载声明并带上同样的 srcset 描述，让它和 CSS 几乎同时开始下载。折叠线以下的图统一走浏览器原生懒加载并加上异步解码，不要引第三方懒加载脚本，那类脚本要等 JS 执行完才开始请求，往往把首图硬生生推后 300 到 600 毫秒。所有图片节点都要写死宽高属性或者用 aspect-ratio 占位，否则图一到位页面就往下跳。轮播图只让第一帧参与首屏加载，后面几帧等用户第一次滑动或者页面空闲时再取。零散小图标合并成一个 SVG 精灵图或直接内联，八个 12KB 的图标各发一个请求，在弱网下的排队时间比它们的体积代价大得多。

校验方法：用 Lighthouse 的移动端配置跑三次取中位数，最大内容绘制控制在 2.5 秒以内，累积布局偏移控制在 0.1 以内。再看瀑布流图，首屏主图的请求应当排在前三个之内发出；如果它排在第十几位，说明还是被脚本接管了，回去检查是不是有懒加载库在全局劫持图片节点。

常见故障与处置

症状一，本地转码明明生成了 WebP，线上返回的还是 JPEG。成因通常是 CDN 的缓存键里没有包含请求头中的 Accept 字段，或者源站没有输出 Vary 声明，导致第一个访问者是老浏览器时，后面所有人都拿到了兜底格式。处置：让运维把 Accept 加进缓存键并配好 Vary，改完刷新全站缓存，再用两种浏览器交叉验证一遍。

症状二，图整体清晰但天空、墙面、渐变背景上出现一圈圈色带。成因是 8 位色深叠加 4:2:0 采样，在平滑过渡区域量化不足。处置有三条：能用 CSS 渐变实现的背景就别用图；必须是图的，把质量值提到 82 以上单独处理这一张；或者这一张改用支持 10 位色深的 AVIF 输出。

症状三，格式全换完了，最大内容绘制时间反而变长。成因有两个方向，一是低端安卓机上 AVIF 解码要花 80 到 160 毫秒，图小了但解得慢；二是首图仍然被脚本接管，下载起步太晚。处置：先看瀑布流确认起步时间，起步晚就先解决劫持问题；确认是解码慢，就把首屏那一张单独退回 WebP，其余图保留 AVIF。

症状四，安卓正常，iPhone 上图位置一片空白。成因多半是 picture 元素里 source 的顺序或 type 值写错，较老版本的 Safari 不认 AVIF，又没匹配到后续 source，最终连兜底的 img 也没生效。处置：把回退链在真机上逐级验证，顺序必须是从新格式到老格式，兜底的 img 标签任何情况下都不能省。

症状五，页面加载过程中内容忽然往下跳一截。成因是图片节点没有宽高信息，布局在图到位前后发生了两次计算。处置：给每个图片节点补上宽高属性，或者在容器上写 aspect-ratio，广告位、第三方嵌入组件同样要预留固定高度。

症状六，上线时各项指标都达标，两三周后又慢回去了。成因几乎都是同一个：编辑在后台直接上传手机拍的原图，绕过了整套转码流程。处置：在上传环节做服务端自动转码，同时加一道拦截规则，长边超过 2000 像素或体积超过 500KB 的直接提示重新处理。这一条属于网页制作交付之后的长期维护约定，写进后台操作手册比口头交代管用。

上线前的自查项

逐条核对：清单上每张图的固有尺寸与渲染尺寸比值都在 1.5 到 2.5 之间；四档尺寸的相邻体积差在 35% 到 60% 区间；网络面板确认首屏图片返回的是 AVIF 或 WebP，且两台真机回退正常；首屏单张不超过 150KB、合计不超过 400KB；每个响应式图片节点的 srcset 与 sizes 成对存在，390 与 768 两种宽度下 currentSrc 取档正确；首屏主图未挂懒加载且请求排在前三；折叠线以下图片全部启用原生懒加载；所有图片节点写有宽高或 aspect-ratio；Lighthouse 移动端三次中位数满足最大内容绘制 2.5 秒、布局偏移 0.1；后台上传通道的自动转码与尺寸拦截已开启并实测过一次。以上任意一项不过，就回到对应步骤重做那一步，不要靠调后面的参数去补前面的账——这也是网页制作里图片这块最容易返工的地方。